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ABSTRACT 


A design knowledge capture (DKC) scheme was implemented using frame- 
based techniques. The objective of such a system is to capture not only the 
knowledge which describes a design, but also that which explains how the design 
decisions were reached. These knowledge types were labelled definitive and 
explanatory, respectively. Examination of the design process helped determine 
what knowledge to retain and at what stage that knowledge is used. A discussion 
of frames resulted in the recognition of their value to knowledge representation 
and organization. The FORMS frame system was used as a basis for further 
development, and for examples using magnetic bearing design. The specific 
contributions made by this research include: 

petermi nation that frame-based systems provide a useful methodology 
for management and application of design knowledge' 

Jp : Definition of specific user interface requirements^ this consists of a 
window-based browsejl* 

' • Specification of syntax for DKC commands; WO 
- i Demonstration of the feasibility of DKC by application to existing de- 
signs. 

It was determined that design knowledge capture could become an ex- 
tremely valuable engineering tool for complicated, long-life systems, but that 
further work was needed, particularly the development of a graphic, window- 
based interface. 
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DKC With A Magnetic Bearing 

Magnetic bearings are becoming increasingly valuable as the identification 
and development of appropriate applications continue. The Advanced Design 
and Manufacturing Laboratory at the University of Maryland, College Park is 
performing extensive research into magnetic bearings as applied to inertial en- 
ergy storage, machine spindle control, and vibration isolation [1, 2], In all cases, 
suspending a load magnetically eliminates friction; the bearing type determines 
if operating power is required. There are three main types of magnetic bearings: 

• Permanent Magnet (PM) 

• Electro- Magnet (EM) 

• Combination Electro and Permanent Magnet (EM/PM) 

Magnetic bearings, along with its subclasses and the three particular systems 
under development at UMCP will be the example for DKC. 

Energy Storage 

The magnetic bearing at UMCP used for flywheel energy storage is a so- 
called pancake bearing. The pancake bearing is a radially- active, axially-passive 
magnetic bearing. That is, the permanent (passive) magnets support all axial 
loads, and the electro-magnets (active) support all radially loads. Proper con- 
trol of electro-magnet currents provides proper radially positioning. The main 
configuration consists of a stack of four (4) ferromagnetic plates: two (2) inner 
(bias flux or magnet) plates, and two (2) outer (control) plates. Sandwiched 
between the inner plates are four (4) symmetrically placed permanent magnets, 
and sandwiched between each outer plate and the corresponding inner plate are 
four (4) electro-magnets. The electro-magnets are wire coils surrounding ferro- 
magnetic control-pins which act as structural elements. To hold the assembly 
together, a bolt is placed as a centerpost, and fastened with a nut. The only 
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other item is epoxy, which is used to fill in slots cut into the magnet plates. (See 
Figure 1) 

The components of the bearing are listed below. 

• Magnet Plate Assembly (1) 

• Magnet Plates (processed) (2) 

• Magnet Plates (2) 

• Epoxy (as required) 

• Permanent Magnets (4) 

• Control Plates (2) 

• Pins (8) 

• Control Coils (8) 

• Bolt (1) 

• Nut (1) 

Machine Spindle Control 

The UMCP spindle control bearing is of the EM type. It has electromagnet 
coils above and below the spindle for axial support, and electromagnet coils 
around the spindle at top and bottom for radial support. Sensor rings provide 
the data needed to drive the electromagnets. The components are listed below. 

• Spindle (1) 

• Thrust Bearing Upper Assembly (1) 

• Thrust Bearing Upper Plate (1) 

• Thrust Bearing Coil (1) 

• Thrust Bearing Lower Assembly (1) 

• Thrust Bearing Lower Plate (1) 

• Thrust Bearing Coil (1) 

• Axial Sensor Ring (1) 
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MAGNETIC SUSPENSION ASSEMBLY 



Figure 1. Magnetic Bearing Assembly Drawing. 
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• Radial Sensor Ring (2) 

• Radial Bearing Top Assembly (1) 

• Radial Bearing lower Assembly (1) 

• Spindle Housing (1) 

• Riser Block (1) 

Vibration Isolation 

The UMCP vibration isolation bearing supports a large, cantilevered, ro- 
tating load. (See Figure 2) 

It too is an EM/PM, radially-active, axially-passive type. The main bearing 
configuration consists of 16 Rare Earth Cobalt (RECO) permanent magnets fit 
into a central ring which is sandwiched between two flux rings. An aluminum 
housing sandwiches eight electromagnet coils (four at each end) and all other 
pieces. 

The components of this bearing are listed below. 

• Central Ring (1) 

• RECO Permanent Magnet (16) 

• Flux Ring (2) 

• Position Transducer Sensor (2) 

• Pole Piece (8) 

• Electromagnet Coil (8) 

• Rotor Spindle Sleeve (1) 

• Touchdown Ball Bearing (2) 

• Draw Rod (8) 

• Aluminum Housing (2) 

• Wave Washer (8) 

• Socket Head Cap Screw (8) 
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Figure 2. Vibration Isolation Magnetic Bearing Device. 




The Magnetic Bearing Hierarchy 

As described, the energy storage and vibration isolation bearings are in- 
stances of the design class of EM/PM magnetic bearings, while the spindle 
control bearing is an instance of the design class of EM magnetic bearings. EM, 
PM, and EM/PM magnetic bearings axe all, in turn, a subclass of magnetic 
bearings, which is a subclass of the general class of bearings. Actually we could 
consider bearings to be a subclass of an even more general design class, such as, 
say, mechanical equipment, but for our purposes there is no reason to do so. In 
this way we have determined the root for our hierarchy. Note the general rule 
which is implied by our choice: 

Choose the root form to be at the highest level from which pertinent 

properties may be inherited, 

which translates into: “be general enough, but not too general.” 

Now consider other possible descendents of the superclasses of our bear- 
ing. For instance, the root class of bearing has subclasses ball bearing and 
roller bearing in addition to magnetic bearing (as well as a plethora of others). 
Similarly, each of these may have subclasses. Considering the magnetic bearing 
subclass, there is PM magnetic bearing and EM magnetic bearing in addition 
to EM/PM magnetic bearing. With this information we can form a hierarchy. 

We could, as discussed, attach our instances of magnetic bearings to the 
appropriate subclasses (i.e EM, PM, EM/PM). However, it’s useful to subdivide 
the design classes first — this time by application, not functionality. That is, 
each type of magnetic bearing will be divided into energy storage, spindle con- 
trol, and vibration isolation. To these subclasses we attach our specific bearings. 
(See Figure 3) 

Because our example bearings are instances of a design class, they have no 
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descendants. This leads to the question of how to represent the components 
of within the hierarchy. Several authors suggest an :IS-PART link analogous 
to the ISA link, but indicative of a component-type relationship [3, 4, 5]. This 
method has the unpleasant side-effect of potentially great redundancy within the 
DKC tree. For example, what if one-hundred different bearings all used the same 
control-pin design? The :IS-PART link would mean having one-hundred identical 
forms, representing the control-pin, spread throughout the tree: a massive waste 
of space. It would be better to have one control-pin form which any other 
form could use; this is the preferred method. This capability is implemented 
by creating a form representing the control-pin. Then a bearing form would 
represent the pin (in fact, all of its components) by a slot whose value would be 
a procedure which references the control-pin form. This way there is only one 
control-pin form; but it may be called by any number of designs. This particular 
mechanism highlights another very important concept: 

Forms may reference other forms through inheritance and through 

explicit procedure calls. 

Now suppose we created forms for each of our components (i.e. coils, housings, 
plates, etc.); where should they be located within the hierarchy? Actually we 
do not have to insert them into the hierarchy — after all, they are not types 
of bearings. However, if they are not inserted, they might not be stored and 
recalled with the bearing hierarchy [implementation dependent], in which case 
we would lose them. There are several alternatives. We could create one big 
hierarchy with a root called something like design and have all our forms fit 
logically within this hierarchy. 

This provides unlimited flexibility, but at the cost of extra effort to create. 
Another possibility is to make another subclass of bearing called auxiliary which 
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is not really a bearing subclass, but just a convenient location to store auxiliary 
forms for bearings. 

This is very convenient, except that it becomes difficult to expand our tree 
beyond bearings. Also there is some inheritance confusion between auxiliary 
and bearing. 

A third alternative is a compromise of the first two. 

We could make the general design form to be our root. This form would 
have the bearing subclass, as well as any others we might create. Additionally, 
it would have the auxiliary subclass in which we could place our components. 
This strategy has several advantage: 

• Auxiliary are part of the Hierarchy. 

• Inheritance is no problem if design has no properties. 

• There is one definite place to put auxiliary forms, rather than a place 
for each subclass. 

• Only two new forms are needed (design, auxiliary), rather than the 
many needed to properly locate singular components. 

• No effort is wasted and no extra effort is needed if a more complete 
hierarchy becomes necessary. 

So configured, the auxiliary parts include standard items such as the bolt, nut, 
and epoxy. The standard nature of these components lends itself to a sub- 
class similar to auxiliary that will contain standard components, as opposed to 
specially designed components. If we call this subclass components , then the 
complete tree for the UMCP Magnetic Bearing can be created. (See Figure 4) 

The Magnetic Bearing Frames 

Having created a design hierarchy for the example bearings, we have cap- 
tured the knowledge implicit in the semantic relationships between design ob- 
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PM Mag. Bear, 
isa 

Magnetic Bearing 


Figure 4. 


Roller Bearing 
isa 

Bearing 


Magnetic Bearing 
isa 

Bearing 


EM Mag. Bear, 
isa 

Magnetic Bearing 


EM/PM Mag. Bear, 
isa 

Magnetic Bearing 


Complete Magnetic Bearing Hierarchy. 
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jects. We have not captured, however, the knowledge intrinsic to the design ob- 
jects themselves. The definitive knowledge may be stored in the frames within 
appropriate slots: drawings, parts lists, sub-part specifications, etc. For each 
sample bearing there would be a drawing slot with an :IF-NEEDED aspect whose 
procedure references the assembly drawing; a set of part slots each with a :NAME 
aspect, a :QUANTITY aspect, an :IF-NEEDED aspect whose procedure referenced 
the appropriate form; and a parts-list slot with an -.IF-NEEDED aspect whose 
procedure returned a list of all the parts belonging to that form. (See Figure 5) 

There is some redundancy between the :NAME and :IF-NEEDED aspects for 
each of the part slots. At present this is necessary because inheritance requires 
a specific slot name, not a pattern for a slot name (i.e. partx). However, 
improvements to the frame system will include this capability. Note that the 
drawing and the parts-list slots also offer a redundancy which inheritance can 
simplify. Because these features are common to designs in general, we can 
define them within the root ( design ) frame, and let all other frames inherit the 
appropriate function calls. (See Figures 6a & 6b) 

Frames for each of the parts of the bearing can be created similarly, but 
with slight differences. Consider the control-pin frame. The pin is an individual 
part: neither a design class nor an assembly. Therefore it will have unique 
characteristics, such as material and manufacturing specifications. Naturally 
the pin will have a mechanical drawing, but this is common to all designs, so 
the control-pin frame can inherit the appropriate procedure. 

It is useful to note that the EM/PM magnetic bearing for energy storage and 
the UMCP pancake magnetic Bearing frames represent the class and instance 
categories of frames, respectively, while the Pin and UMCP pancake magnetic 
bearing frames represent the piece-part and assembly categories of frames, re- 
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UMCP Pancake Magnetic Bearing 
ISA 

EM/PM Mag. Bear, for Energy Storage 

Drawing :IF-NEEDED (get-drawing) 

Parti :NAME Magnet-Plate- Assembly 

:IF-NEEDED (Get Magnet-Plate-Assembly) 
QUANTITY 1 

Part2 :NAME Control-Plate 

:IF-NEEDED (Get Control-Plate) 
:QUANTITY 2 

Part3 :NAME Control-Coil 

:IF-NEEDED (Get Controol-Coil) 
:QUANTITY 8 

Part4 :NAME Control-Pin 

:IF-NEEDED (Get Control-Pin) 

QUANTITY 8 

Part5 :NAME Bolt 

:IF-NEEDED (Get Bolt) 

:QUANTITY 1 

Part 6 :NAME Nut 

:IF-NEEDED (Get Nut) 

QUANTITY 1 

Parts-list :IF-NEEDED (get-parts-list) 


Figure 5. Example Magnetic Bearing Frame. 
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DESIGN 


ISA 

root 

Drawing :IF-NEEDED (get-drawing) 
Parts-list :IF-NEEDED (get-parts-list) 


6a 


UMCP Pancake Magnetic Bearing 
ISA 

EM/PM Mag. Bear.for Energy Storage 


Parti 

:NAME 

Magnet-Plate- Assembly 


:QXJANTITY 

1 

Part2 

:NAME 

Control-Plate 


QUANTITY 

2 

Part3 

:NAME 

Control-Coil 


QUANTITY 

8 

Part4 

:NAME 

Control-Pin 


:QUANTITY 

8 

Part5 

:NAME 

Bolt 


:QUANTITY 

1 

Part6 

:NAME 

Nut 


QUANTITY 

1 


6b 


Figure 6. Example Design and Magnetic Bearing Frames. 
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spectively. Because these sets of characteristics are orthogonal, a matrix can 
be created to demonstrate the four possible characterizations of a given frame. 
(See Figure 7) 

To this point we have captured design knowledge regarding the configura- 
tion of design objects (hierarchy and component specifications), and the geomet- 
ric definitions of the design objects (detail and assembly drawings). However, 
the characteristics of the classes within the hierarchy should be considered. For 
example, all bearings have certain characteristics, such as load-carrying capa- 
bility, frictional coefficient, etc. We need to include these slots in the bearing 
frame, and to provide appropriate default values. For the above characteristics 
the values depend greatly on unknown considerations (such as bearing type), 
so appropriate values are “wide-range.” Thus any design object which inherits 
from bearing will have a default coefficient of friction of “wide-range.” But any 
bearing, or class of bearings with a known value should specify it. A major ad- 
vantage of magnetic bearings is zero friction, so the magnetic bearing frame will 
declare the friction coefficient slot to have a value of zero. The effect is that a 
UMCP magnetic bearing (or any other magnetic bearing) will inherit this value. 

The load-carrying characteristic demonstrates a common design dilemma. 
For EM/PM magnetic bearings (for which the permanent magnets support the 
load), the load-carrying characteristics can be determined functionally by an- 
alyzing the bearing design. However, these characteristics might actually be 
parameters which drive the design. Therefore a knowledge capture decision 
must be made: is the load-carrying capability an input or an output? In this 
case, as in many design situations, there is a specification range (often a min- 
imum or a maximum), any value in which is satisfactory. This lends itself to 
two slots: a load-carrying specification, and a load-carrying actual value. This 
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Class 

Instance 


EM/PM Magnetic 

UMCP Pancake 

Assembly 

Bearing for 
Energy Storage 

Magnetic Bearing 


Pin 

Control-Pin 

Piece-part 

Coil 

Control- Coil 


Figure 7. Frame Classification Matrix. 
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way a program for calculating the actual value can be assigned to the EM/PM 
Mag. Bear, class, for all EM/PM magnetic bearings to inherit; and each specific 
EM/PM magnetic bearing can specify its own system requirements. Example 
frames containing this characteristic data are shown in Figures 8a, 8b, 9a, & 9b. 

Continuing in this manner we could incorporate a wealth of knowledge 
about bearings, magnetic bearings, EM/PM magnetic bearings, the UMCP mag- 
netic bearings, and any other design objects within the hierarchy. But this would 
be continuing to deal exclusively with the knowledge which defines and describes 
the design objects. Attention must be paid to the knowledge which explains. 

Consider again the control-pin. As previously indicated, its frame would 
have a material slot; for this case the value of the slot would be “nickel iron 
alloy.” However, at present there is no way to provide an explanation of this 
choice within the frame. Creating a new aspect called :DOC for the material slot 
solves this problem. Then by assigning this aspect a value of “to permit high 
flux levels on the order of 1.5 Teslas without saturation,” we capture this elusive 
chunk of knowledge and store it systematically. (See Figure 10a) 

Note that although it is cumbersome to display documentation within a 
graphical representation of a frame, the DKC system has no corresponding diffi- 
culty. 

The :DOC aspect can be used with any slot — so every characteristic of a 
design object may have documentation logically associated with it. One possi- 
bility with piece-parts is to create a slot for each feature, much as assemblies 
have a slot for each sub-part. Not only would this allow feature inheritance, but 
also appropriate documentation for each feature. Such documentation might 
seem to do no more than verbalize information contained by the drawings. For 
example, a feature labelled main-diameter belonging to the control-pin might 
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Bearing 


ISA 

Design 

Frictional 

Coefficient = wide-range 

Load- Carrying 

Capability = wide-range 


8a 


Magnetic Bearing 
ISA 

Bearing 

Frictional 

Coefficient = zero 


8b 


Figure 8. Characteristic Inheritance Frames I. 
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EM/PM Mag. Bear. 


ISA 

Magnetic Bearing 
Load-Carrying 

Capability :IF-NEEDED (calc-load-cap) 


9a 


UMCP Pancake Mag. Bear. 

ISA 

EM/PM Mag. Bear, for Energy Storage 

Load-Carrying = 2g acceleration 
Requirement of load 


9b 


Figure 9. Characteristic Inheritance Frames II. 
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Control- Pin 


ISA 

Auxiliary 

Material = nickel-iron-alloy 

:DOC to permit high flux levels 
on the order of 1.5 Teslas 
withou saturation. 


10a 


Material 


Control-Pin 

ISA 

auxiliary 

nickel-iron-alloy 


:DOC 

to permit high flux levels 

Featurel 

:NAME 

on the order of 1.5 Teslas 
withou saturation. 

main-diameter 


=s 

.800l o ooi 0 n -) 


:DOC 

to mate with the Control- Coil. 


10b 


Figure 10. Documentation within Frames. 
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have a value of 0.800 in qoi* with an explanation w to mate with the control- 
coil.” (See Figure 10b) But this does more than reiterate drawing data: it shows 
causality. That is, upon perusing the drawings it might be unclear whether the 
coil size determined the pin size or vice versa. This documentation relieves the 
ambiguity, and redirects attention to the appropriate form. 

The part slots within an assembly form may use the :DOC aspect in an anal- 
ogous fashion to feature slots of piece-parts. Considering the pancake bearing, 
and specifically the part4 slot (control-pin), it’s clear that the documentation 
for any slot should do two things: 

• explain the need/use of the part. 

• explain any additional information. 

For part4 this means: 

• explain the need/use of the control-pin. 

• explain why there are eight (8). 

Similar documentation would be appropriate for other slots. Additionally, a 
documentation slot could be created to contain general information about the 
entire object. Figure 11 shows the example frame with these modifications. 
Figures 12 and 13 show, respectively, the spindle control and vibration isolation 
example bearing frames. 

The Magnetic Bearing Knowledge Base 

Having developed an understanding of magnetic bearings, the frames which 
represent them, and the hierarchy in which they fit, we can populate the knowl- 
edge base. For purpose of example, a few parts from each of the UMCP magnetic 
bearings were considered and implemented. In certain cases there was similar- 
ity between parts of different bearings, and when appropriate, DKC mechanisms 
were used to take advantage of it. 
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UMCP Pancake Magnetic Bearing 


ISA 

EM/PM Mag. Bear, for Energy Storage 


Documentation 

:GOAL 

support an energy 
storage flywheel 

Paxtl 

:NAME 

Magnet-Plate-Assembly 


QUANTITY 

1 


:DOC 

the permanent magnet 
sub- assembly 

Part2 

:NAME 

Control-Plate 


iQUANTITY 

2 


:DOC 

top and bottom plates 
(contain the electro-magnets) 

Part3 

:NAME 

Control-Coil 


QUANTITY 

8 


:DOC 

to generate controlling 
magnetic fields 

Part4 

:NAME 

Control-Pin 


IQUANTITY 

8 


IDOC 

conductive center structure 
for control-coils 

Part5 

INAME 

Bolt 


iQUANTITY 

1 


IDOC 

stack fastener 

Part6 

INAME 

Nut 


iQUANTITY 

1 


IDOC 

stack fastener 


Figure 11. UMCP Energy Storage Magnetic Bearing Frame. 
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UMCP Spindle Control Magnetic Bearing 
ISA 

EM Spindle Control Magnetic Bearing 


Documentation 

‘.GOAL 

Parti 

:NAME 

QUANTITY 

Part2 

:NAME 

:QUANTITY 

Part3 

:NAME 

QUANTITY 

Part4 

:NAME 

QUANTITY 

Part5 

:NAME 

QUANTITY 

Part6 

:NAME 

QUANTITY 

Paxt7 

‘.NAME 

QUANTITY 

Part8 

:NAME 

QUANTITY 

Part9 

:NAME 

rQUANTITY 


Control of a High- 
Accuracy Machining Spindle 

Spindle 

1 

Thrust Bearing Upper Plate 

1 

Thrust Bearing Lower Plate 
1 

Thrust Bearing Coil 

2 

Radial Sensor Ring 

2 

Axial Sensor Ring 

1 

Radial Bearing Top Assembly 

1 

Radial Bearing Lower Assembly 

1 

Spindle Housing 

1 


Figure 12. UMCP Spindle Control Magnetic Bearing Frame 
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UMCP Vibration Isolation Magnetic Bearing 
ISA 

EM/PM Vibration Isolation Magnetic Bearing 


Documentation 

:GOAL 

isolate vibrations 
of a rotating load 

Parti 

:NAME 

Central Ring 


QUANTITY 

1 

Part2 

:NAME 

Flux Ring 


:QUANTITY 

2 

Part3 

:NAME 

Pole Piece 


QUANTITY 

8 

Part4 

:NAME 

Aluminum Housing 


QUANTITY 

2 

Part5 

:NAME 

Draw Rod 


QUANTITY 

8 

Part6 

:NAME 

Electromagnet Coil 


:QUANTITY 

8 

Part7 

:NAME 

Socket Head Cap Screw 


:QUANTITY 

8 

Part8 

:NAME 

Wave Washer 


QUANTITY 

8 

Part9 

:NAME 

Touchdown Ball Bearing 


QUANTITY 

2 

PartlO 

:NAME 

Position Transducer Sensor 


:QUANTITY 

2 

Part 11 

:NAME 

RECO Permanent Magnet 


QUANTITY 

16 

Partl2 

:NAME 

Rotor Spindle Sleeve 


QUANTITY 

1 


Figure 13. UMCP Vibration Isolation Magnetic Bearing Frame. 
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The magnet plate is the first part of the pancake bearing to be designed. 
The principal parameters are diameter, thickness, pole face angle, pole face 
thickness, and material saturation level. These five parameters are indepen- 
dent, and different combinations will yield different bearing characteristics. The 
selection of these values is based upon experience, intuition, and iterative test- 
ing. However, certain heuristic knowledge exists: 

• pole face thickness < 1/16 x diameter 

• plate thickness > 1.75 x pole face thickness This knowledge is incorpo- 
rated as a recommended range which a designer may accept or override. 
But he either case, he has referenced the information. 

The electromagnetic coils of the pancake bearing have much less indepen- 
dence than the magnet plates. The fundamental parameters are diameter, wire 
diameter, and number of turns. The diameter is determined uniquely by the 
control-pin diameter. Therefore the coil frame has a slot labelled “diameter” 
with an :IF-NEEDED aspect that fetches the pin diameter and processes it ap- 
propriately (determined by type of fit). The wire diameter is constrained by 
several other parameters, so that slot has a procedure to calculate the resultant 
constraint. The number of turns is constrained by flux requirements and space 
limitations, but is not determined uniquely. Therefore, when a value is spec- 
ified an :IF- ADDED procedure checks for consistency and returns appropriate 
information. The coil, thus, has demonstrated a significant difference regarding 
design constraints. If the constraints uniquely determine the value, then an :IF- 
NEEDED function can be attached for this purpose. But if the constraints only 
restrict the value, then an :IF-ADDED may be implemented to assure this. 

The riser block of the UMCP spindle control magnetic bearing provides 
a mechanical interface between the spindle assembly and the machine body. 
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The most obvious features, the holes, axe determined by the mounting holes 
on the mating surfaces. Also, the block thickness is determined by spindle po- 
sition requirements. As before, these values are implemented via :IF-NEEDED 
aspects. The remaining riser block parameters are less clear-cut. The material, 
aluminum, is based upon weight minimization given strength and stiffness re- 
quirements. In reality, aluminum was chosen because the designer knew it was 
appropriate. In theory, the strength and stiffness requirements would be spec- 
ified and an :IF-NEEDED procedure would select the lightest available material 
(from a data base) which satisfied these conditions. 

The complex face geometries correspond to the most interesting design 
knowledge of the block. As with material, the driving influence was weight min- 
imization given the strength and stiffness requirements. As there are innumer- 
able configurations, the design must be based upon experience, and, probably, 
some limit case analyses. This demonstrates the difficulty of applying DKC to 
the synthesis phase of design. 

The UMCP vibration isolation magnetic bearing, like most magnetic bear- 
ings, can maintain suspension as long as displacements are small (due to non- 
linearities). Therefore ball-bearings are incorporated into the design to act as a 
backup system. Before the rotor can displace too far, it will engage the backup 
bearings and allow the magnetic circuitry to re-effect suspension. The design of 
the backup bearings is a two part job. First is to determine the radius; second 
is the actual bearing design, which is associated with the ball-bearing sub-class 
of the general bearing hierarchy. Determining the radius requires calculating 
the range of static controllability, which in turn requires knowing the maximum 
bearing force and the static stiffness. Then, as a rule-of-thumb, the backup 
bearing is given a radius 90% of the range of static controllability. Because 
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this method determines exactly the backup bearing radius, it is implemented 
with an :IF-NEEDED. However, the procedure assumes it will be able to find (or 
compute) the force and stiffness. If this data had not been established previ- 
ously, the :IF-NEEDED would not have succeeded. Additionally, once the radius 
is known, the actual ball bearing design is implemented with an :IF-NEEDED; 
but because the ball-bearing hierarchy is empty, this procedure is inoperative. 

The design methodology for the electromagnet coils is similar to that for 
the coils of the pancake bearing. So rather than duplicating that information, 
one coil frame describes the general methodology, and each bearing accesses 
that frame. Moreover, because the methodology is (usually) appropriate for any 
EM/PM magnetic bearing, we can place the link to the coil frame within the 
EM/PM magnetic bearing subclass frame, and let all our instances inherit from 
it. 

In many case we may have defined already a design object in several loca- 
tions. This actually occurred with the coil of the preceding section. In these 
situations it is appropriate to locate every such occurrence and replace them with 
pointers to a single frame. Fortunately the DKC search functions and frame ma- 
nipulation functions simplify this process into a few basic commands. Indeed, a 
macro could (and should) be written to do all this in one step. 

Recommendations and Conclusions 

The future of Design Knowledge Capture depends upon its development 
now. This thesis has presented many critical aspects of DKC, but a lot of 
additional work will be needed before an initial attempt at a complete system 
can be implemented. This work can be divided into three main categories: 

• System Definition and Coding 

• Computer Science Development 
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• Prototyping 

The initial DKC system presented here provides a template for increasingly 
sophisticated system definition; many of these definitions will be motivated by 
advances in the field of knowledge engineering. Therefore it is immensely impor- 
tant to monitor the state-of-the-art of knowledge engineering, expert systems, 
and related areas of AI. As we have discovered, AI techniques are the only 
tools available for generating this type of system, and AI is a fast-paced and 
ever-changing field. 

Many other improvements of the DKC definition will come from the expe- 
rience of developing code to satisfy existing definitions. Frequently the devel- 
opment of computer code produces a heightened awareness of a more general 
problem. This translates into superior system definition, and the cycle contin- 
ues. Therefore, there must be a continued, dedicated effort to develop code 
implementing the current definition even though it may cause its own obsoles- 
cence: that is precisely the point. However, when developing code, it would be 
worthwhile to follow the maxim: 

write tools, not programs. 

This means that programs should not be “hacked” together just to get some- 
thing working, but developed systematically to assure future compatibility and 
expandability. Some areas where the system definition might be enhanced are: 

• Additional frames commands. 

• Additional slot aspects (e.g. :DOC, :IS-PART). 

• Multiple parents (=$► resolution of inheritance ambiguities). 

• Procedural calls to other environments (e.g. call a DOS-based design 
program). 

This research has made the following specific contributions: 
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• Determination that frame-based systems provide a useful methodology 
for management and application of design knowledge. 

• Definition of specific user interface requirements; this consists of a 
window-based browser. 

• Specification of syntax for DKC commands. 

• Demonstration of the feasibility of DKC by application to existing de- 
signs. 

Future considerations for the advancement of DKC include creating the 
graphic interface, prototyping many different systems, monitoring the state-of- 
the-art in related areas, and increasing the involvement of computer science 
personnel. 
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